Currently often applied in plants of process automation technology are field devices, which control processes running in the plant and/or register a measured variable. Such field devices are composed, for example, of a measurement transmitter, to which at least one measuring transducer is connected, which serves for registering a chemical and/or physical, measured variable. Also considered field devices are display- and/or service units, which are used or installed on-site in the plant. These field devices are currently often connected with one another via a fieldbus. In this way, the field devices can exchange with one another and/or with a control unit, which controls the process, information such as, for example, measured values. Known from the state of the art for data transmission via such a fieldbus are various fieldbus protocols.
Furthermore, there are, for example, in the case of the HART protocol different groups of commands. In such case, one distinguishes between universal commands, which are also referred to as basic commands, and general commands, which are also referred to as common practice commands. Furthermore, there are in the case of the HART protocol also device-specific commands.
Also the Profibus protocol is similarly constructed. Its commands can be divided, for example, into basic commands and manufacturer-specific commands. In giving manufacturer-specific commands for the functioning of a field device, it is taught in the state of the art, such as known, for example, from Published international application, WO 2012041616 A1, that a particular command should be unequivocally defined and not, for example, trigger different functions in different field devices connected to the fieldbus.
Field devices are, as a rule, configured via device description based, host systems. These device description based, host systems and service devices, respectively operating programs, give a developer or a service person no control over the point in time and the sequence, in which parameters, respectively parameter sets, are written into the field device. For, depending on system, parameters are written in a fixed sequence into the field device, when via a user interface a change of the parametering is performed. This can lead to problems in practice, since parameters cannot always be changed independently of one another, for often there are dependencies between individual parameters of a field device. Therefore, it is in the case of a parameter change advantageous, when all parameters affected by the dependence are transmitted in a certain sequence to the field device and stored there, in order that no recursive dependency resolutions are required. Above all, in safety-critical applications, a known write sequence of parameters is important.
Another requirement is the writing of an entire parameter set (download) into the field device. In this case, the dependencies between the parameters are resolved by the host system, for example, a control unit, which is connected with the field device via the fieldbus. Thus, the performance of the field device can clearly be increased, when it is known to the field device that a download is taking place, for then it is not necessary that the field device calculate, respectively resolve, dependencies between the parameters during the download.
Furthermore, in the case of a download, the field device does not have to bring about persistence in a non-volatile memory, which can, for example, be integrated in the field device, after the receipt of each parameter, but can, instead, create the persistence after the download is completed, i.e. operate on all downloaded parameters at once.